\chapter{Protótipo}
\label{prototipo}

Conhecendo a proposta elaborada pelo projeto anterior, bem como as tecnologias utilizadas para a composição do mesmo, podemos então partir para a elaboração do protótipo funcional. Este é o principal objetivo deste trabalho, pois somente através dele poderemos ver todo o processo proposto funcionando de forma sequencial e integrada. Assim, poderemos avaliar se a escolha das tecnologias foram feitas corretamente e se essas tecnologias conseguem interoperar de forma satisfatória. 

Este protótipo é desenvolvido utilizando-se a linguagem Java e dará origem a duas aplicações \textit{stand-alone}, uma para o módulo coletor, outra para o módulo de autenticação.

\section{Integração e melhorias}

Foram desenvolvidas no projeto anterior diversas provas de conceito, que visavam mostrar que as tecnologias poderiam ser utilizadas da forma proposta. No entanto, nenhum esforço foi feito no sentido de integrá-las. Nesta seção veremos o que foi realizado no projeto anterior e como isso pôde ajudar neste projeto.

\subsection{Impressão digital}

Uma pesquisa completa sobre impressões digitais foi realizada no trabalho anterior. Todos os conceitos foram novamente abordados neste trabalho na seção \ref{tecnologiaImpressaoDigital}, de forma a proporcionar o entendimento desta tecnologia e do seu uso neste trabalho.

Foi também elaborada no trabalho anterior uma pequena prova de conceitos sobre leitura eletrônica de impressões digitais. Para tal, foi utilizado o \textit{kit} de desenvolvimento da Griaule \cite{GRIAULE}, que fornece a \textit{API} Java capaz de manipular leitores de impressões digitais, extrair \textit{templates} das imagens obtidas, fazer o \textit{matching} dos \textit{templates}, dentre outras coisas. A figura \ref{figuraProvaConceitoImpressaoDigital} mostra a imagem de uma digital lida através da prova de conceito desenvolvida.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.4}{\includegraphics{imagens/provaConceitoImpressaoDigital.png}}
   \end{center}
   \caption{Prova de conceito da leitura de impressões digitais usando a \textit{API} da Griaule \cite[p.85]{LPS}\label{figuraProvaConceitoImpressaoDigital}}
\end{figure}

Apesar de ter sido dado um grande passo, muitas coisas ainda precisaram ser feitas. A primeira delas foi melhorar o código fonte para que o controlador do dispositivo de impressão digital fosse incializado e finalizado de maneira adequada, no momento correto. Outras mudanças foram feitas para criar uma interface que permitisse o desacoplamento das classes da API da Griaule, deixando o serviço disponível de forma simples para o código do protótipo. Dessa forma seria muito mais fácil usar o leitor de digital nos vários pontos onde este é necessário, podendo o mesmo código de leitura e codificação do \textit{template} ser aproveitado nos dois módulos descritos nas seção \ref{prototipoOrganizacaoLogica}.

A versão da API da Griaule utilizada foi a 2009, que possui suporte a plataformas 64 bits e pode ser utilizada em diversos sistemas operacionais, além de corrigir vários bugs existentes na versão 2007, usada na prova de conceito realizada no projeto anterior.

\subsection{Captura do número de inscrição}
\label{melhoriaNumeroInscricao}

Grandes avanços foram feitos pelo trabalho anterior no que se refere ao processamento das imagens do cartão resposta, com o intuito de identificar o número de inscrição do candidato. Foi desenvolvida uma aplicação em Matlab que recebe como entrada uma imagem com o cartão resposta e retorna o número de inscrição contido no mesmo. A figura \ref{figuraProvaConceitoLeituraCartao} mostra a aplicação sendo executada, no processo de leitura do cartão resposta.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.4}{\includegraphics{imagens/provaConceitoLeituraCartao.png}}
   \end{center}
   \caption{Prova de conceito da leitura do número de inscrição, feita usando MATLAB \cite[p.86]{LPS}\label{figuraProvaConceitoLeituraCartao}}
\end{figure}

Apesar da aplicação em Matlab estar funcionando adequadamente dentro do Matlab, nenhum esforço foi feito no sentido de integrar esta aplicação ao ambiente Java onde poderia ser utilizada juntamente com as outras provas de conceito. Coube a este projeto pesquisar e implementar essa integração.

Para poder utilizar a aplicação Matlab desenvolvida dentro do ambiente Java, primeiramente foi pesquisada uma API disponibilizada pela própria empresa desenvolvedora do Matlab, o \textit{Matlab Java Builder} \cite{MATLABJAVA}. As pesquisas com esta API foram muito bem sucedidas e atenderam perfeitamente ao objetivo buscado. Foi então elaborado um serviço Java que pode ser utilizado de forma simples quando necessário. Este serviço proporciona um isolamento entre as classes do protótipo e o código de baixo nível que manipula os scripts do Matlab. Desta forma ficou simples fazer a leitura do número de inscrição com imagens provenientes da câmera ao invés de utilizar arquivos estáticos, de forma perfeitamente integrada ao restante do código Java.

\subsection{QRCode}

Uma ampla pesquisa sobre códigos de barras bidimensionais também foi realizada no trabalho anterior, ficando comprovado que o QRCode é a tecnologia mais adequada para a aplicação neste trabalho. Uma revisão conceitual foi feita na seção \ref{tecnologiaCodigoBarras} de forma a permitir o entendimento do uso desta tecnologia neste protótipo. Na figura \ref{figuraProvaConceitoQRCode} temos uma imagem da prova de conceito desenvolvida, que era capaz de codificar um determinado conjunto de informações em um simbolo QRCode e também decodificar esse conjunto de informações a partir do símbolo.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.4}{\includegraphics{imagens/provaConceitoQRCode.png}}
   \end{center}
   \caption{Prova de conceito do processamento do QRCode, utilizando o projeto ZXing \cite[p.91]{LPS}\label{figuraProvaConceitoQRCode}}
\end{figure}

Essa prova de conceito era capaz de codificar um QRCode dado um texto digitado na caixa de texto e também de capturar imagens da câmera digital ou do disco rígido e decodificá-las. Para capturar as imagens era usada a API JMF, melhor detalhada na seção \ref{capturaImagens}, e a API ZXing \cite{ZXING} para fazer a codificação e decodificação das imagens.

Apesar de bem desenvolvida, a pesquisa anterior não realizou os cálculos referentes ao dimensionamento do QRCode de forma muito confiável. Isso ocorreu pois o \textit{template} foi representado de forma inadequada, como podemos ver com detalhes em \cite[p.86 a 91]{LPS}. Ao invés de se codificar diretamente a sequência de \textit{bytes} do \textit{template} para a construção do símbolo, esta sequência foi transformada em uma sequência de caracteres composta apenas por algarismos e o símbolo `-'. A transformação foi feita da seguinte forma:

Vamos supor que o \textit{template} da digital é composto da sequência de \textit{bytes}: [-12, 35, -1, -126, 4]. Esta é uma simplificação para que possamos entender o problema, pois na realidade o template tem muito mais que 5 \textit{bytes}. De forma resumida, o que foi feito foi pegar a representação textual de cada \textit{byte} na sua forma numérica (como está escrito acima) e formar uma cadeia de caracteres numéricos, dessa forma: [-1235-1-1264]. Isso nos permitiria tirar proveito do modo de codificação para caracteres numéricos do \textit{QRCode}. No entanto, esta transformação tem alguns problemas que serão descritos abaixo:

\begin{itemize}

\item \textbf{Conversão aumenta o volume de dados} - Enquanto um \textit{byte} precisa de 8 \textit{bits} para ser armazenado, um dígito numérico precisa de apenas 4 \textit{bits}. No entando o que não foi levado em conta é que a representação textual de um número que caiba em um \textit{byte} pode ter até 3 dígitos (4 contando com o sinal de negativo), o que nos traz na verdade uma desvantagem nessa conversão. O \textit{byte} -126, por exemplo, que precisa de 8 \textit{bits} para ser representado com \textit{byte}, se convertido dessa forma vai precisar de 4 \textit{bits} para cada caracter, o que nos consumiria 16 \textit{bits}. Realmente há vantagem, mas apenas para os números de 1 dígito, que são apenas 10. Mesmo convertendo os \textit{bytes} sempre para números positivos (de 0 a 255), temos 10 bytes onde há vantagem na conversão (0 a 9), todos os outros \textit{bytes} (10 a 255) gastam 8 \textit{bits} ou mais.  

\item \textbf{Necessidade de um separador} - Como o número de \textit{bits} que cada \textit{byte} do template vai precisar usar é variável depois de convertido, ainda precisaríamos de um caracter separador. A sequência do exemplo acima, após convertida sem uso do separador, ficaria assim: -1235-1-1264. Dessa forma é impossível reconstituir a sequência original. Esta mesma sequência convertida, por exemplo, poderia ter sido originada dos \textit{bytes} [-12, 3, 5, -1, -12, 6, 4], que é bem diferente do \textit{template} original. Este caracter separador precisaria ser armazenado, o que ainda consumiria mais espaço no QRCode.

\end{itemize}

Dessa forma, para que o template fosse codificado de forma reversível, usando a menor quantidade de dados possível, foram testados alguns algoritmos de compactação binária. Estes algoritmos simplemente pegam um \textit{array} de \textit{bytes} e transformam em outro \textit{array} de \textit{bytes} compactado. Na tabela \ref{tabelaCompressao} podemos ver os algoritmos e as taxas de compressão média obtidas para os templates:

\begin{table}[h]
\caption{Níveis de compressão\label{tabelaCompressao}} 
\center{
\begin{tabular}{l|l}
\hline
Algoritmo   & Taxa de compressão média (\% volume original)\\
\hline
gzip                 & 88\% \\
bzip2              & 98\% \\
zlib                 & 86\% \\
\hline
\end{tabular}}
\end{table}

Por ter a melhor compressão e também ser provido por padrão dentro da plataforma Java, o ZLIB foi escolhido para compactar as informações a serem gravadas no QRCode. Esse processo de compactação é feito de forma independente e não tem relação alguma com o algoritmo do QRCode. Imediatamente antes de solicitar ao ZXing que condifique as informações, estas são compactadas. De forma análoga, imediatamente depois de ler as informações do QRCode estas são descompactadas e voltam ao seu estado original.

No que se refere a implementação em si, foi necessário fazer uma atualização da \textit{API} ZXing, que é a responsável pela codificação e decodificação do QRCode. A versão utilizada na prova de conceito era bem antiga, tinha vários bugs já corrigidos e sua performance era bem pior que a versão atual, 1.6. Essa migração não foi tão simples como esperado, pois muitos pontos da \textit{API} foram bastante reformulados, mas após entender essas modificações e realizar a migração foi obtida uma melhora significativa.

\subsection{Captura de imagens}
\label{capturaImagens}

Na prova de conceito do QRCode descrita na seção anterior, foram feitas algumas pesquisas no que se refere a captura de imagens. No processo de decodificação do QRCode, precisamos obter a imagem do símbolo para que o mesmo possa ser decodificado. Isso foi feito utilizando-se uma câmera digital simples que fornecia imagens para a API ZXing. Para auxiliar o fiscal a apontar a câmera corretamente para o símbolo, precisamos mostrar a imagem atual da câmera na tela do sistema. Tanto para a captura quanto para a exibição foi utilizada a API JMF -- Java Media Framework -- \cite{JMF}, que possibilita, dentre outras coisas, a exibição de vídeos provenientes de dispositivos de captura, como câmeras digitais. É possível também obter quadros desses vídeos atrvés da API.

Apesar de possuir as funcionalidades necessárias, o JMF trazia um nível de complexidade desncessário para este protótipo. Para exibir a imagem na tela, por exemplo, era necessário instanciar um \textit{Player}, configurar a fonte -- no caso a câmera -- para este \textit{Player} e ainda colocar este objeto dentro da aplicação de forma correta. Outro problema era a forma de capturar um quadro para fazer o processamento, pois também era preciso solicitar ao \textit{Player} um dos quadros que ele estava exibindo, não sendo possível, por exemplo, capturar uma imagem com alta resolução e exibir no \textit{Player} apenas uma amostra da imagem capturada, com baixa resolução.

Dessa forma foi necessário pesquisar uma alternativa ao JMF. A solução mais adequada encontrada foi utilizar a API LTI-Civil \cite{LTICIVIL}, que tem como objetivo ser uma API de código aberto, multiplataforma, que permite capturar imagens de \textit{webcams} e dispositivos semelhantes. Esta API, ao contrário do JMF, não possui nenhuma ferramenta para exibição das imagems capturadas, serve apenas como uma espécie de leitor do dispositivo de captura. A princípio isso parece uma desvatagem, mas na verdade a simplicidade neste caso se mostrou vantajosa. A exibição das imagens deixou de ser feita com o \textit{Player} do JMF e passou a ser feita através de um componente visual simples. Outra vantagem de se abandonar o \textit{Player} é a desvinculação do procedimento de captura do dispositivo e da exibição da imagem capturada na tela. É possível, por exemplo, capturar uma imagem com o LTI-Civil com resolução de 1200x900 e exibí-la na tela numa região de 320x240, o que é muito importante para não deixar a interface lenta e permitir o uso do sistema em telas de baixa resolução, ao mesmo tempo sem limitar a resolução da imagem que será processada.

Outro ponto importante, que demandou uma flexibilização maior desse componente de captura de imagens, é o fato de que este será usado não somente para a leitura do QRCode, mas também para a leitura da imagem do número de inscrição. Foi necessário implementar um capturador de imagens que pudesse usar diferentes resoluções em cada ponto onde for utilizado. 

\subsection{Impressão}

Pouco foi pesquisado sobre este tópico no trabalho anterior. Foram feitas apenas pesquisas de equipamentos que pudessem ser úteis ao projeto, mas nada foi pesquisado em termos de \textit{software}. Para viabilizar a contrução deste protótipo mais pesquisas nesta área precisariam ser feitas.

Primeiramente foi necessário procurar uma impressora virtual, pois seria inviável fazer várias impressões de teste em uma impressora real. Para isso foi utilizada a ferramenta PDF Creator \cite{PDFCREATOR}, que nada mais é do que uma impressora que ao invés de imprimir para um papel imprime para um arquivo PDF. Assim podemos fazer inúmeros testes e imprimir numa impressora real quando desejar.

Quanto a realização da impressão em si, nada muito complexo precisou ser feito. A plataforma Java já disponibiliza classes simples que permitem executar esta tarefa. Foi elaborada então uma classe que posiciona alguns componentes visuais e o símbolo do QRCode numa página, além de algumas informações extras. Essa página é então impressa para a impressora virtual de PDFs. Na solução final basta trocar a impressora para uma real, e então o QRCode será impresso num papel gomado no formato de uma etiqueta, que será colada no cartão resposta.

\section{Organização Lógica}
\label{prototipoOrganizacaoLogica}

Após desenvolvidas as funcionalidades faltamtes, esta seção descreverá os módulos coletor e de autenticação, mostrando como as diversas tecnologias se integram dentro dos diversos processos envolvidos. Veremos em detalhes todos os procedimentos executados em cada etapa do processo.

\subsection{Módulo Coletor}
\label{prototipoColeta}

O módulo coletor tem como objetivo coletar os dados do indivíduo que está se apresentando para realizar a prova, registrando confiavelmente tudo que for necessário para a conferência da identidade deste indivíduo no futuro. Para tal, são coletados os seguintes itens: identificação do fiscal de prova, impressão digital do candidato e número de inscrição existente no cartão resposta. De posse desses itens, o sistema imprime uma etiqueta com um código de barras bidimensional contendo essas três informações. Todas essas etapas são realizadas sem a intervenção direta do fiscal, ficando este apenas responsável por conduzir o processo para garantir que tudo correrá conforme o esperado.  

A princípio somente a digital seria suficiente para prover um bom nível de confiabilidade, mas amarrar esta informação ao número de inscrição do candidato traz ainda mais segurança: não é possível que haja uma troca de etiquetas, pois neste caso o número de inscrição contido na etiqueta trocada não seria o mesmo constante no cartão resposta em que esta está colada. Também é desestimulada a corrupção dos fiscais ao vincular a identificação dos mesmos, pois em caso de fraudes com as etiquetas também seria possível identificá-los.

Ao ser aberto, o sistema solicita a identificação do fiscal, também através da impressão digital. Após autenticar o fiscal, o sistema fica então aguardando um candidato. Para cada candidato, o sistema obtem o número de inscrição do cartão resposta, coleta as impressões digitais e imprime a etiqueta que deve ser colada no cartão resposta. Cada uma dessas etapas está detelhada a seguir.

\subsubsection{Identificação do Fiscal}
\label{prototipoColetaFiscal}

Nesta etapa será garantida a autenticidade do fiscal que aplica as provas, através da coleta da impressão digital do mesmo. Logo após iniciar, o módulo coletor fica aguardando que o fiscal coloque o dedo sobre o leitor de impressão digital. Após obtê-la, o sistema verifica se o indivíduo está presente no banco de dados de fiscais credenciados para aplicar a prova. Caso não esteja, o sistema então solicita novamente a digital até que uma identificação existente no banco de dados seja fornecida, passando então para a próxima fase. A figura \ref{figuraPrototipoColetorFiscal} mostra o protótipo nesta etapa.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoColetorFiscal.jpg}}
   \end{center}
   \caption{Módulo coletor na etapa de autenticação do fiscal\label{figuraPrototipoColetorFiscal}}
\end{figure}

Esta etapa é realizada apenas uma vez, logo após a abertura do módulo. Uma vez autenticado, o fiscal poderá realizar a coleta de todos os candidatos sem precisar se identificar novamente. O nome do fiscal atualmente ativo no sistema fica disponível na região inferior do mesmo durante as outras etapas para que o candidato possa conferir este nome com a identificação física (crachás ou qualquer outro documento válido) disponível.

\subsubsection{Espera do candidato}
\label{prototipoColetaEspera}

Esta etapa do processo não tem nenhuma função na coleta dos dados do candidato propriamente dita, existe apenas para que o sistema possa sinalizar que está pronto para iniciar o processo do próximo candidato. O fiscal deve clicar no botão `Prosseguir' logo após a chegada do próximo candidato para realizar a identificação durante as próximas etapas. A figura \ref{figuraPrototipoColetorAguardando} ilustra esta tela.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoColetorAguardando.jpg}}
   \end{center}
   \caption{Módulo coletor aguardando a coleta do próximo candidato\label{figuraPrototipoColetorAguardando}}
\end{figure}

\subsubsection{Captura do número de inscrição}
\label{prototipoColetaNumero}

Durante a fase de obtenção do número de inscrição do candidato, o sistema de captura de imagens fica acionado ininterruptamente exibindo as imagens fornecidas pela câmera para que o fiscal possa posicioná-la corretamente sobre o cartão resposta. Assim que posicionar a câmera, o fiscal deve pressionar o botão `Ler código' enquanto a câmera é mantida apontada especificamente para a região do cartão onde está o código de inscrição -- região B da figura \ref{figuraCartaoRespostaAreas} --, permitindo que o módulo de reconhecimento de imagens processe as imagens vindas do módulo de captura e obtenha o número de inscrição. A resolução utilizada na captura da imagem é de 320x240 \textit{pixels}, que mostrou ser a de melhor performance dentro das resoluções disponíveis. A figura \ref{figuraPrototipoColetorFiscal} mostra o módulo coletor logo após realizar a leitura de um número de inscrição.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoColetorInscricao.jpg}}
   \end{center}
   \caption{Módulo coletor após ter lido o número de inscrição\label{figuraPrototipoColetorInscricao}}
\end{figure}

Para que seja garantido um índice de confiabilidade no reconhecimento do código do cartão, o sistema realiza automaticamente várias leituras, pois seria inseguro assumir o primeiro número lido como correto. No entanto, o tempo de processamento de cada imagem é muito maior que o tempo de captura, o que impossibilita o processamento de todos os quadros enviados pela câmera. Sendo assim, o módulo de processamento pega sempre a última imagem capturada antes de cada tentativa de identificação. Após cada leitura, o módulo de processamento pega novamente a última imagem capturada e processa, repetindo esse procedimento até que, segundo a heurística descrita a seguir, possa ser garantida a corretude do número lido. 

Conforme dito acima, essa repetição visa diminuir a possibilidade de erro na leitura do código de inscrição, mas precisamos definir como escolher o número correto dentre essas várias leituras, que podem ter resultados distintos. Considerando a eficácia do módulo de processamento de imagem elaborado anteriormente \cite[p. 36]{LPS}, numa série suficientemente grande de leituras teremos mais ocorrências para o número correto. Sendo assim, depois de algumas análises experimentais, a seguinte heurística foi adotada: Fazemos tantas leituras quanto forem necessárias até que o número de maior frequência tenha cinco ocorrências a mais que o segundo número de maior frequência. Então tomamos esse número com maior frequência como o número correto. 

Para deixar mais claro essa metodologia adotada, veremos uma simulaçao de leituras na tabela \ref{tabelaParadaLeituraInscricao}.

 
\begin{table}[h]
\caption{Simulação de leituras para decisão do número correto\label{tabelaParadaLeituraInscricao}} 
\centering
\begin{tabular}{|l|l|}
\hline
Número		& Ocorrências\\
\hline
2341678		& 8\\
\textcolor{red}{1}341678		& 3\\
\textcolor{red}{12}41678		& 1\\
\hline
Total		& 12\\
\hline
\end{tabular}
\end{table}

Neste exemplo, o sistema consideraria o número 2341678 como correto, pois este teve 5 ocorrências a mais que o segundo número que mais ocorreu, 1341678.

Caso não haja um segundo número, então cinco leituras de um mesmo valor são suficientes para considerar o número correto. Há também um tempo limite para a extração, que é de trinta segundos. Depois deste tempo, será considerado correto o número com maior frequência, independente da diferença de ocorrência para os demais. Essa decisão tomada com base no tempo pode ser menos segura, mas é necessário ter um tempo limite para os casos onde o sistema não conseguir realizar muitas leituras, devido a condições ruins de luminosidade, cartão preenchido com tinta fraca, etc.

Após lido o número de inscrição, o fiscal pode ainda conferir o número informado com o cartão resposta antes de prosseguir. Caso o número esteja incorreto, pode ser solicitada ao sistema uma nova leitura e o processo descrito acima será repetido. O fiscal tem a possibilidade de repetir a leitura quantas vezes precisar, mas por motivos de segurança não é permitido digitar manualmente o número de inscrição.

\subsubsection{Coleta das digitais}
\label{prototipoColetaDigital}

Nesta fase o sistema ativa o leitor de digitais para que possam ser capturadas as amostras da digital do candidato. O leitor permanece ativado até que esta fase seja concluída com sucesso. Na tela são mostradas as imagens das impressões digitais que estão sendo capturadas, além de um indicador de quantas amostras já foram capturadas e quantas ainda faltam. Dessa forma, o fiscal e o candidato podem acompanhar o processo de coleta. O sistema passa automaticamente para a próxima etapa após a coleta de todas as amostras. A figura \ref{figuraPrototipoColetorDigitais} a seguir mostra o sistema durante esta etapa de coleta.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoColetorDigitais.jpg}}
   \end{center}
   \caption{Módulo coletor aguardando a terceira amostra da digital do candidato\label{figuraPrototipoColetorDigitais}}
\end{figure}

Conforme dito na seção \ref{moduloColetorOriginal}, o trabalho anterior previa que três amostras deveriam ser coletadas e a que possuísse o maior template deveria ser utilizada. Apesar do maior template realmente possuir o maior número de minúcias dentre as amostras, essa abordagem não é a ideal, pois algumas minúcias capturadas somente nas amostras com templates menores serão descartadas. Sendo assim, neste projeto continuaremos coletando 3 amostras, porém utilizaremos o processo de \textit{enrolling} disponível na API da Griaule. Neste processo, descrito com mais detalhes na seção \ref{tecnologiaImpressaoDigital}, as três amostras obtidas são consolidadas ao invés de ser escolhida a maior, permitindo a utilização das minúcias coletadas em todas as amostras.

\subsubsection{Geração e impressão da etiqueta}
\label{prototipoColetaEtiqueta}

Nesta fase o sistema executa a geração e impressão do QRCode que será gravado no cartão resposta. De posse do número de inscrição do cadidato, do template da digital, e do número do fiscal de prova responsável, o sistema tem então todas as informações necessárias para gerar o símbolo que será impresso na etiqueta. A figura \ref{figuraPrototipoColetorEtiqueta} mostra o sistema logo após de gerar o símbolo QRCode com todas essas informações.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoColetorEtiqueta.jpg}}
   \end{center}
   \caption{Módulo coletor após gerar o QRCode contendo as informações do candidato\label{figuraPrototipoColetorEtiqueta}}
\end{figure}

Para a codificação do QRCode precisamos juntar essas três informações em uma sequência de \textit{bytes} ordenada, tornando possível a recuperação desses dados na etapa de decodificação. A tabela mostra \ref{tabelaSequenciaCodificada} mostra em qual posição foi colocada cada uma dessas informações nesta sequência.

\begin{table}[h]
\caption{Disposição das informações na sequência de \textit{bytes} codificados\label{tabelaSequenciaCodificada}} 
\centering
\begin{tabular}{|l|l|}
\hline
Trecho de \textit{bytes}		& Informação contida\\
\hline
1 a 4		& Número de identificação do fiscal \\
5 a 8		& Número de inscrição do candidato \\
9 ao fim	  & Template da digital\\
\hline
\end{tabular}
\end{table}

Conforme descrito na seção \ref{tecnologiaCodigoBarras}, para que pudéssemos minimizar a quantidade de \textit{bytes} sendo colocadas no símbolo do QRCode, essa sequência de \textit{bytes} é ainda compactada utilizando-se o algoritmo ZLIB, o que reduz em média o tamanho para 86\% do original.

Após gerada essa sequência compactada, então podemos gerar o símbolo QRCode. Podemos considerar que o cartão resposta é um documento que será bem conservado, o que nos permite usar um nível de correção de erros baixo. Será então usado o nível de correção de erros L -- níveis de correção estão detalhados na tabela \ref{tabelaQRCodeCorrecaoErro} --, que nos traz um nível de tolerância e não onera muito a capacidade de armazenamento.

Ao solicitar a codificação de uma sequência de \textit{bytes} para a API ZXing é preciso fornecer a altura e largura máxima, especificada em células. Para este trabalho, estes limites de altura e largura podem ser de 250 células. Fornecida então a sequência de \textit{bytes} a ser codificada, os limites de altura e largura e o nível correção de erro desejado, a API nos retorna uma matriz de \textit{bits} com no máximo as dimensões passadas, que então precisa ser convertida para uma imagem. Para realizar esta conversão, os \textit{bits} 1 da matriz são convertidos para pontos pretos na imagem, enquanto os \textit{bits} 0 são convertidos para pontos brancos.

De posse da imagem, precisamos montar a etiqueta. No trabalho anterior esperava-se poder colocar a etiqueta com o símbolo gerado no mesmo local onde atualmente fica a digital coletada manualmente -- vide figura \ref{figuraDigitalEletronica} --. No entanto, isso não será possível devido aos seguintes fatores:

\begin{itemize}

\item \textbf{Aumento da quantidade de informações armazenadas} - Como descrito na seção \ref{prototipoColetaDigital}, não será mais armazenado um \textit{template} simples, mas sim um \textit{template} originado num processo de \textit{enrolling}, que é muito mais rico em minúcias e, consequentemente, tem um número maior de \textit{bytes}. A estimativa do projeto anterior era de no máximo 500 \textit{bytes} codificados, enquanto agora este número gira em torno de 800 \textit{bytes}. Isso aumenta consideravelmente a área necessária para o símbolo.

\item \textbf{Facilidade de leitura} - Os cálculos no projeto anterior \cite[p.86 a 91]{LPS} foram baseados no limite mínimo teórico do QRCode, sem considerar os fatores e adversidades que podem prejudicar a leitura, como falhas de impressão, condições não ideais de luminosidade, etc. Imprimir um símbolo em uma área pequena pode impossibilitar a leitura das informações num segundo momento, o que inviabiliza a solução proposta. Além do mais, não foram realizados testes reais de leitura para o estabelecimento desta área como viável.

\end{itemize}

Considerando essa impossibilidade, temos como alternativa a utilização da área disponível no verso do cartão resposta para colocação da etiqueta. Essa área permite a impressão do símbolo de forma confiável, respeitando a zona de silêncio especificada pelo QRCode e permitindo também uma maior resolução, o que facilita bastante a leitura. Temos ainda outra vantagem, que é facilidade maior para utilização dos tamanhos de etiqueta disponíveis no mercado. No trabalho anterior essa dificuldade foi apontada, pois não existiam etiquetas disponíveis que coubessem na área antes designada para a aplicação da etiqueta, na frente do cartão.

Utilizando então o verso do cartão, o sistema imprime o QRCode, juntamente com a data e hora correntes, envoltos por uma borda, que seria a área colante do papel gomado. Neste protótipo, no entanto, não foi utlizado papel gomado. Todos os testes foram feitos imprimindo o símbolo diretamente no verso do cartão resposta ou em uma folha separada, que depois foi anexada ao cartão resposta. A figura \ref{figuraEtiqueta} mostra o resultado dessa impressão.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/etiqueta-qrcode.jpg}}
   \end{center}
   \caption{Etiqueta impressa contendo o símbolo QRCode\label{figuraEtiqueta}}
\end{figure}

\newpage

\subsection{Módulo de Autenticação}

O módulo de autenticação tem como objetivo coletar os dados do indivíduo que está assumindo a vaga, comparando os dados fornecidos por ele neste momento com os dados fornecidos no momento da aplicação da prova. Para fazer esta conferência o sistema vai obter as informações existentes no cartão resposta, fazendo a leitura do símbolo QRCode impresso no momento da realização da prova. De posse dos dados do símbolo, o sistema vai coletar a digital do candidato aprovado e enfim fazer a verificação das digital, emitindo um parecer a respeito da autenticidade do candidato. Cabe ao agente conduzir esse processo e instruir o candidato através das etapas do procedimento de verificação, não havendo nenhuma intervenção direta.

Ao ser aberto, o sistema solicita a identificação do fiscal, também através da impressão digital. Após autenticar o fiscal, o sistema fica então aguardando um candidato. Para cada candidato, o sistema lê o simbolo QRCode do cartão resposta, coleta as impressões digitais e emite o parecer da autenticação. Cada uma dessas etapas está detelhada nas proximas seções.

\subsubsection{Identificação do Fiscal}
\label{prototipoIdentificacaoFiscal}

De forma análoga ao módulo coletor, nesta etapa também será garantida a autenticidade do agente responsável pela efetivação da aprovação do candidato, através da coleta da impressão digital do mesmo. Logo após iniciar, o módulo de identificação fica aguardando que o agente coloque o dedo sobre o leitor de impressão digital. Após obtê-la, o sistema verifica se o indivíduo está presente no banco de dados de agentes credenciados para realização da efetivação. Caso não esteja, o sistema então solicita novamente a digital até que uma identificação existente no banco de dados seja fornecida, passando então para a próxima fase. A figura \ref{figuraPrototipoAutenticadorFiscal} mostra o sistema depois de identificado o agente.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoAutenticadorFiscal.jpg}}
   \end{center}
   \caption{Modolo autenticador após identificar o agente\label{figuraPrototipoAutenticadorFiscal}}
\end{figure}

Esta etapa é realizada apenas uma vez, logo após a abertura do módulo. Uma vez autenticado, o agente poderá realizar a identificação de todos os candidatos sem precisar se identificar novamente. O nome do agente atualmente ativo no sistema fica disponível na região inferior do mesmo durante as outras etapas para que o candidato possa conferir este nome com a identificação física (crachás ou qualquer outro documento válido) disponível.

\subsubsection{Espera do candidato}
\label{prototipoIdentificacaoEspera}

Esta etapa do processo não tem nenhuma função na identificação do candidato propriamente dita, existe apenas para que o sistema possa sinalizar que está pronto para iniciar a identificação do próximo candidato. O agente deve clicar no botão `Prosseguir' assim que iniciar a efetivação do próximo candidato aprovado. A figura \ref{figuraPrototipoAutenticadorAguardando} ilustra esta tela.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoAutenticadorAguardando.jpg}}
   \end{center}
   \caption{Módulo autenticador aguardando a coleta do próximo candidato\label{figuraPrototipoAutenticadorAguardando}}
\end{figure}

\subsubsection{Leitura do QRCode}

Durante a fase de leitura do QRCode do cartão resposta, o sistema de captura de imagens fica acionado ininterruptamente exibindo as imagens fornecidas pela câmera para que o fiscal possa apontá-la para o QRCode no verso do cartão resposta. Assim que posicionar a câmera, o fiscal deve pressionar o botão `Ler QRCode' enquanto a câmera é mantida apontada para o símbolo, permitindo que a API ZZing processe as imagens vindas do módulo de captura e obtenha as informações contidas no QRCode. A figura \ref{figuraPrototipoAutenticadorQRCode} mostra esta etapa após a leitura do QRCode.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoAutenticadorQRCode.jpg}}
   \end{center}
   \caption{Módulo autenticador após leitura do QRCode\label{figuraPrototipoAutenticadorQRCode}}
\end{figure}

A resolução utilizada na captura da imagem é de 800x600 \textit{pixels}, que mostrou ser a melhor dentre as resoluções disponíveis para a leitura do símbolo. Resoluções menores não tinham a qualidade suficiente para a leitura, enquanto resoluções maiores geravam imagens grandes, que demoravam muito para serem processadas.

Há um tempo limite para esta leitura, que é de trinta segundos. Depois de decorrido este tempo, o sistema exibe uma mensagem informando uma falha na leitura. O agente pode então solicitar a leitura novamente para que o processo continue. Depois de lido o QRCode, o número de inscrição do candidato, que está codificado, é exibido na tela. O agente pode então conferir este número. Em caso de erro -- o agente pode ter usado o cartão resposta errado, por exemplo --, pode ser solicitado ao sistema uma nova leitura. Não há limite para solicitações de nova leitura. 

Quanto a confiabilidade dos dados lidos, temos dentro do próprio algoritmo de decodificação do QRCode um sistema de \textit{checksum}, que invalida a leitura realizada caso os dados tenham sido lidos de forma incorreta. Podemos então considerar que sempre que houver um retorno do método de decodificação teremos informações confiáveis. 


\subsubsection{Leitura da Digital}

Nesta etapa o sistema pede para que o candidato coloque seu dedo no leitor de digitais, a fim de comparar com a digital coletada no dia da realização da prova. Este processo de coleta é feito de forma bem semelhante ao realizado no dia da prova, porém apenas uma amostra é suficiente para emitir um parecer positivo. Caso o processo de \textit{matching} entre a digital coletada e a digital lida do QRCode dê um resultado positivo, então o sistema passa para a próxima etapa emitindo um parecer positivo. Caso o resultado seja negativo, então o sistema solicita por até mais duas vezes uma coleta de impressão digital do candidato. Após três resultados negativos, então os sistema exibe o parecer negativo. A figura \ref{figuraPrototipoAutenticadorDigital} mostra o protótipo nesta etapa, após um resultado negativo.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoAutenticadorDigital.jpg}}
   \end{center}
   \caption{Módulo autenticador após ler uma digital do candidato\label{figuraPrototipoAutenticadorDigital}}
\end{figure}

\subsubsection{Parecer final}

Esta etapa serve apenas para exibir o parecer de acordo com o resultado da etapa anterior. Caso o teste de \textit{matching} tenha dado positivo, então uma imagem de `Ok' é exibida na tela, juntamente com a mensagem dizendo que o candidato está corretamente identificado. Caso o teste tenha dado negativo, então uma imagem falha é exibida, juntamente com uma mensagem informado que o candidato está em situação fraudulenta. A figura \ref{figuraPrototipoAutenticadorParecer} mostra o sistema após a emissão de um parecer positivo.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/prototipoAutenticadorParecer.jpg}}
   \end{center}
   \caption{Módulo autenticador emitindo parecer positivo\label{figuraPrototipoAutenticadorParecer}}
\end{figure}

\section{Organização Física}

Nas seções a seguir detalharemos os dispositivos utilizados, bem como a disposição física dos mesmos.

\subsection{Dispositivos}

Os dispositivos usados neste protótipo estão descritos nos tópicos a seguir.

\begin{itemize}

\item \textbf{\textit{Laptop}} - Um \textit{laptop} comum está sendo utilizado, embora fosse perfeitamente possível a utilização de um \textit{netbook} neste protótipo. O processador é um Intel Core 2 Duo P8700, de 2.53Ghz, e a memória é de 4GB. No entanto, esta aplicação poderia rodar em um equipamento muito abaixo dessas especificações.

\item \textbf{\textit{webcam}} - A \textit{webcam} utilizada foi uma NEOX NXW036, que é um dispositivo de captura de imagens de baixo custo. As resoluções suportadas por esse dispositivo são 160x120, 176x144, 320x240, 352x288, 640x480, 800x600, 1280x960 e 1600x1200. Neste trabalho estão sendo usadas as resoluções 320x240 para o número de inscrição e 800x600 para a leitura do QRCode.

\item \textbf{Leitor de digitais} - O leitor de impressoes digitais utilizado neste protótipo foi o U.are.U 4000b, fabricado pela Digital Persona. Este leitor possui resolução de 512 dpi e é um dos suportados pela API da Griaule.

\item \textbf{Impressoras} - Durante os testes foi utilizada basicamente a impressora virtual de PDFs. Nos testes realizados com impressões em papel, foi utilizada a impressora HP Photosmart D110a. Alguns testes também foram realizados com a impressora HP Laserjet P2055dn para efeitos de comparação.

\end{itemize}

\subsection{Disposição}

A estrutura deste protótipo funcional está bastante similar a proposta no projeto anterior, como podemos ver na figura \ref{figuraEsquemaFisico}. No entanto, neste projeto, a câmera não lê somente o número de inscrição do cartão resposta, mas também o QRCode gerado para realizar a autenticação. A impressora real também não foi utilizada conectada diretamente ao sistema, tendo sido utilizada uma impressora PDF. A impressora real foi utilizada somente em alguns momentos, para imprimir as etiquetas gravadas em PDF.

\begin{figure}[h]
   \begin{center}
     \scalebox{0.5}{\includegraphics{imagens/esquemaFisico.jpg}}
   \end{center}
   \caption{Esquema físico do protótipo\label{figuraEsquemaFisico}}
\end{figure}
